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1. Abstract 

The Small Computer Systems Interface (SCSI) is a popular family of 
protocols for communicating with I/O devices, especially storage 
devices. This memo describes a transport protocol for SCSI that 
operates on top of TCP. The iSCSl protocol aims to be fully com- 
pliant with the requirements laid out in the SCSI Architecture 
Model - 2 [SAM2] document - 

2. Overview 

2.1. SCSI Concepts 

The endpoint of most SCSI commands is a "logical unit" (LU). Exam- 
ples of logical units include hard drives, tape drives, CD and DVD 
drives, printers and processors, within the logical unit the 
abstract entity that executes the SCSI commands is named the 
device-server. A "target" is a collection of logical units, in 
general of the same kind, and is directly addressable on the net- 
work. In large installations a target is known also as a "control 
unit". The target corresponds to the server in the abstract SAM 
client-server model. An "initiator" creates and sends SCSI com- 
mands to the target- The initiator corresponds to the client in the 
abstract SAM client-server model. A "task" is a linked set of SCSI 
commands. Some LUNs support multiple pending (queued) tasks. The 
target uses a "task tag* to distinguish between tasks, only one 
command in a task can be outstanding at any given time. A SCSI 
command results in an optional data phase and a response phase. In 
the data phase, information travels either from the initiator to 
the target, as in a WRITE command, or from target to initiator, as 
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in a READ command. In the response phase, the target returns the 
* final status of the operation, including any errors. A response 
terminates a SCSI command. 

2.2. iSCSl Concepts & Functional Overview 

2.2.1. Layers & Sessions 

The following conceptual layering model is used in this document to 
specify initiator and target actions and how those relate to 
transmitted and received Protocol Data Units: - SCSI layer 
builds/receives SCSI CDB (Command Data Blocks) and relays/receives 
them with the remaining command execute parameters (cf. SAM-2) 
to/from the - iscsi layer that builds/receives iscsi PDUs and 
relays/receives them to/from - one or more TCP connections that 
form an initiator-target "session" 

Communication between initiator and target occurs over one or more 
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TCP connections. The TCP connections are used for sending control 
messages, SCSI commands, parameters and data within iscsi Protocol 
Data Units (iscsi pdu) . The group of TCP connections linking an 
initiator with a target form a session (loosely equivalent to a 
SCSI nexus); a session is defined by a session ID (composed of an 
initiator part and a target part). TCP connections can be added and 
removed from a session. 

2.2.2. Ordering and iscsi numbering 

iscsi supports ordered command delivery within a session. All com- 
mands (initiator-to-target) and responses (target-to-initiator) are 
numbered. Any SCSI activity is related to a task (sam-2) . The task 
is identified by the initiator Task Tag for the life of the task. 

Commands in transit from the initiator SCSI layer to the target 
SCSI layer are numbered by iscsi and the number is carried by the 
iscsi PDU as CmdRN (command-Reference-Number). All iscsi PDUs that 
have a task association carry this number. CmdRNs are allocated by 
the initiator iscsi as an increasing counter wrapping around from 
2**32-1 to 1. The 0 value is reserved and used to mean immediate 
delivery. The target may choose to deliver some task management 
commands for immediate delivery. The means by which the SCSI layer 
may request immediate delivery for a command or by which iSCSl will 
decide by itself to mark a PDU for immediate delivery are yet to be 
defined. CmdRNs are significant only during command delivery to the 
target. Once the device serving part of the target SCSI has 
received a command, CmdRN ceases to be significant. The initiator 
and target are assumed to have three registers that define the 
allocation mechanism - CmdRN - the current command reference number 
advanced by 1 on each command shipped; ExpCmdRN - the next expected 
command by the target - acknowledges all commands up to it; 
MaxCmdRN - the maximum number to be shipped - defines the queuing 
capacity of the receiving iSCSl. CmdRN can take any value from 
ExpCmdRN to MaxCmdRN except 0. The target will reject any command 
outside this range or duplicates within the range not flagged with 
the retry bit (the X bit in the opcode). The target and initiator 
registers are supposed to uphold causal ordering. 

Responses in transit from the target to the initiator are also num- 
bered. The statRN (status Reference Number) is used for this pur- 
pose. If the target uses data packet numbering and all the inbound 
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data have been acknowledged, or the target "is able to regenerate 
inbound data, then the target may free all the resources allocated 
for the task execution just after sending a response. The same 
holds for targets not allowing full command recovery. The result 
summary, just enough to rebuild the status PDU, will be kept by 
those iSCSl target implementations that support status recovery 
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after connection failure. As the only cause for long delays in 
responses can be failed connections and received responses free-up 
resources, we felt that score boarding responses at the initiator 
could be accomplished by simple bitmaps and there is no need to 
flow-control responses. Status acknowledgment is done by the ini- 
tiator through ExpStatRN (Expected Status RN) and large difference 
between StatRN and ExpStatRN indicates a failed connection . 

iscsi initiators are required to implement the numbering scheme if 
they support more than one connection. 

iSCSl targets are not required to use the numbering scheme for 
ordered delivery even when they support multiple connections. How- 
ever they are required to provide ExpCmdRN and MaxCmdRN values that 
will enable the initiator to make progress. 

The NOP PDUs are not associated with a task, are meant for immedi- 
ate delivery, and their only purpose is synchronizing the ordering 
registers of the target and initiator. 



2.2.3. iSCSl Login 

The purpose of iSCSl login is to enable a TCP connection for iSCSI 
use, authenticate the parties, authorize the initiator to send SCSI 
commands and mark the connection as belonging to a iscsi session. 
A session is used to identify to a target all the connections with 
a given initiator. The targets listen on a well-known TCP port for 
incoming connections. The initiator begins the login process by 
connecting to that well-known TCP port. As part of the login pro- 
cess, the initiator and target MAY wish to authenticate each other. 
This can occur in many different ways. For example, the endpoints 
may wish to check the IP address of the other party, if the TCP 
connection uses transport layer security [TLS] , certificates may be 
used to identify the endpoints. Also, iSCSl includes commands for 
identifying the initiator and passing an authenticator to the tar- 
get (see Appendix B) . Once suitable authentication has occurred, 
the target may authorize the initiator to send SCSI commands. How 
the target chooses to authorize an initiator is beyond the scope of 
this document. The target indicates a successful authentication 
and authorization by sending a login response with "accept login". 
The login message includes a session ID - composed with an initia- 
tor part ISID and a target part TSID. For a new session the TSID is 
null. AS part of the response the target will generate a TSID. 
Session specific parameters can be specified only for the first 
login of a session (TSID null)(e.g., the maximum number of connec- 
tions that can be used for this session). Connection specific 
parameters (if any) can be specified for any login. Thus a session 
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is operational once it has at least one connection. After authen- 
tication and authorization, other parameters may be negotiated 
using the highly extensible Text Command message that allows arbi- 
trary keyrvaiue pairs to be passed. Any message sent on a TCP con- 
nection before this connection gets into full feature phase at the 
initiator should be rejected by the initiator. A message reaching 
a target on a TCP connection before the full feature phase will be 
rejected with an iscsi check condition. 

2.2.4. iscsi Full Feature Phase 

Once the initiator is authorized to do so, the iscsi session is in 
iscsi full feature phase. The initiator may send SCSI commands and 
data to the various LUNs on the target by wrapping them in iscsi 
messages that go over the established iSCSl session. For SCSI com- 
mands that require data and/or parameter transfer, the (optional) 
data and the status for a command must be sent over the same TCP 
connection that was used to deliver the SCSI command (connection 
allegiance). Thus if an initiator issues a READ command, the tar- 
get must send the requested data followed by the status to the ini- 
tiator over the same TCP connection that was used to deliver the 
SCSI command. If an initiator issues a WRITE command, the initia- 
tor must send the data for that command and the target must return 
the status over the same TCP connection that was used to deliver 
the SCSI command- During iscsi Full Feature Phase, the initiator 
and target may interleave unrelated SCSI commands, their SCSI Data 
and responses, over the session. Outgoing SCSI data (initiator to 
target - user data or command parameters) is sent as either unsoli- 
cited data or solicited data. Unsolicited data can be part of an 
iscsi command pdu ("immediate data") or an iscsi data PDU. Soli- 
cited data are sent in response to Ready To Transfer pdus. Targets 
operate in either solicited (RTT) data mode or unsolicited (non 
RTT) data mode. An initiator must always honor an RTT data 
request. It is considered an error for an initiator to send unsol- 
icited data PDUs to a target operating in RTT mode (only solicited 
data). An initiator is allowed to send immediate data even to tar- 
gets working in RTT mode. An initiator may request, at login, to 
send immediate data of any size and a target may indicate the size 
of immediate data blocks it is ready to accept in its response. A 
target is allowed to silently discard data and request retransmis- 
sion through RTT. Initiators will not perform any score boarding 
for data and the residual count calculation is to be performed by 
the targets, incoming data is always solicited. However an initia- 
tor will be able to request retransmission of all or part of the 
target data. SCSI Data packets are matched to their corresponding 
SCSI commands by using Tags that are specified in the protocol. 
Initiator tags for pending commands are unique initiator-wide for a 
session. Target tags for pending commands are unique target-wide 
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for the session. Although the above mechanisms are designed to 
accomplish efficient data delivery and a large degree of control 
over the data flow it is recognized that some specific sequences 
involving ordered execution and a mix of solicited and immediate 
data can result in deadlocks. It is for this reason that discarding 
data by a target is considered a legitimate action. Each iSCSI ses- 
sion to a target is treated as if it originated from a different 
initiator. 

2.2.5. iSCSl Connection Termination 
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Connection termination is assumed to be an exceptional event. 
Graceful TCP connection shutdowns are done by sending TCP FiNs. 
Graceful connection shutdowns MUST only occur when there are no 
outstanding tasks that have allegiance to the connection. A target 
SHOULD respond rapidly to a FIN from the initiator by closing its 
half of the connection as soon as it has finished all outstanding 
tasks that have allegiance to the connection, closing a connection 
that has outstanding tasks may require recovery actions and will Be 
described elsewhere in this document. 

2.2.6. Naming & mapping 

Targets are named using an URL type name of the format: 

scsi : //<domai n-name> [/modi f i er] 



The name used to connect will be optionally included in the login 
in order to enable the target to present different views. This is 
the Target Acquired Name (TAN). We will not attempt to define 
which components of the name will participate in the name resolu- 
tion process and which ones will be used only for "view" defini- 
tion. The syntactic sugar included might be used to introduce 
structure for management purposes but has no specific significance 
for this standard. Example: 

scsi : //di skf arml . acme . com 

scsi : //computi ngcenter . acme . com/peri pheral s/di skf arml 



when a target has to act as an initiator for a third party command 
it will use the TAN during login as required by the authentication 
mechanism. A domain name that contains exactly four numbers 
separated by dots (.), where each number is in the range 0 through 
255, will be interpreted as an IPv4 address. Examples: 
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10.0.0.1/tapefarml 
10.0.0.2 



Likewise a domain name that contains more than four, but less than 
16 numbers separated by dots (.), where each number is in the range 
0 through 255, will be interpreted as an lpv6 address. Examples: 

12 . 5 . 7 . 10 . 0 . 0 . 1/tapef arml 
12.5.6.10.0.0.2 



To address targets and logical units within a target SCSI uses a 
fixed length (8 bytes) uniform addressing scheme; in this document 
we call those addresses SCSI reference addresses (SRA) . 

To provide the target with the protocol specific addresses (iscsi 
or FC) iSCSl uses a Map Command; the Map command sends the managing 
target the protocol specific addresses and gets from the target the 
SRAs to use in subsequent commands. For iscsi a protocol specific 
address is a TCP address and a view; those can be expressed as 
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lowed by a view or in text form. After mapping iSCSl will be pro- 
vided with a handle to the address in standard SCSI format. 
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3. Message Formats 

All multi-byte integers specified in formats defined in this docu- 
ment are to be represented in network byte order (i.e., big 
endian) . 

3.1. Template Header and Opcodes 

All iSCSl messages and responses have a header of the same length 
(48 bytes). Additional data may be added, as necessary, beginning 
with byte 48. The fields of Opcode and Length appear in all message 
and response headers. The other most commonly used fields are Ini- 
tiator Task Tag, Logical Unit Number, and Flags, which, when used, 
always appear in the same location of the header. 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 0|7 654321 0|7 654321 0|7 654321 01 
+ + + + _(. 

01 Opcode I Opcode-specific fields I 
+ + + + + 

4 1 Length of Data (after 48 byte Header) I 
^ + + + + 

8 I LUN or Opcode-specific fields I 

+ + 

121 I 
^ + ^ + + 

161 Initiator Task Tag I 
+ + + + + 

20/ Opcode-specific fields / 

+/ / 
+ + + + + 

48 

Page 8 



draft-satran-iscsi -Ol.txt 

3ri,l. opcode 

The Opcode indicates which iSCSl type of messaqe or response is 
encapsulated by the header. The opcode is further encoded as fol- 
lows: 

b7 Retry Command/Response (x bit) 
b6 Response 
b5-0 Operation 

Valid opcodes for messages (sent by initiator to target) are: 
0x00 NOP-Out Message (from initiator to target) 
0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) 
0x02 SCSI Task Management command 
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0x03 Login Command 
0x04 Text Command 

0x05 SCSI Data (for WRITE operation) 

0x09 Ping command (from initiator to target) 

OxOa Map Command 

valid opcodes for responses (sent by target to initiator) are: 
0x40 NOP-ln Message (from target to initiator) 
0x41 SCSI Response (contains SCSI status and possibly sense 

information or other response information) 
0x42 SCSI Task Management Response 
0x43 Login Response 
0x44 Text Response 
0x45 SCSI Data (for READ operation) 

0x46 Ready To Transfer (RTT - sent by target to initiator when 

it is ready to receive data from initiator) 
0x47 Asynchronous Event (sent by target to initiator to indicate 
certain special conditions) 
0x48 Opcode Not understood 

0x49 Ping Response (from target to initiator) 
0x4a Map Response 



3.1.2. Length 

The Length field indicates the number of bytes, beyond the first 48 
bytes, that are being sent together with this message header. It is 
anticipated that most iSCSl messages and responses (not counting 
data transfer messages) will not need more than the 48 byte header, 
and hence the Length field will contain the value 0. it is 
expected that larger than 16 byte CDBs and parameter data will fol- 
low the header. 

3.1.3. LUN 

The LUN specifies the Logical unit for which the command is tar- 
eted. If the command does not relate to a Logical Unit, this 
ield is either ignored or may be used for some other purpose. 
According to [SAM2] , a Logical unit Number can take up to a 64-bit 
field that identifies the Logical Unit within a target device. The 
exact format of this field can be found in the [SAM2] document. 

3.1.4. Initiator Task Tag 

The initiator assigns a Task Id (or tag) to each SCSI task that it 
issues. (Recall that a task is a linked set of SCSI commands.) 
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uniquely identify the Task. 
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3.1.5. Opcode-specific fields 

These field have different meanings for different messages. 
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3.2. SCSI Command 
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Byte / 0 

17 6 5 4 3 2 10 
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1 



76543210 



2 I 3 I 

I I 
7654321 017 654321 01 



01 Opcode (0x01) |I I|R| Rsrvd |A| Rsvrd |ATTR | Reserved (0) | 
4. + + + + 

4 1 Length I 

^ + -}_ + + 

81 Logical Unit Number (LUN) I 
+ + 
121 I 
+ + + + -+ 

161 Initiator Task Tag I 
+ + 4. + + 

201 Expected Data Transfer Length I 
+ + + -|. + 

24 1 cmdRN I 
_,_ + + + + 

281 ExpStatRN I 



32/ SCSI command Descriptor Block (CDB) / 

+/ / 
4. 4. + + 4. 

48/ Additional Data (Command Dependent) / 

+/ / 
+ 4. + + 4. 



3.2-1. Flags. 



The flags field for a SCSI Command consists of two bytes. 
Byte 1 - iSCSl flags 

b7-6 (I) Immediate Data from initiator to target (command 

parameters/write/control); this field indicates also how 
to interpret the length field: 

00 - Immediate Data Length = Length; CDB Length = 16 

01 - CDB Length = Lengtn+16; Immediate Data Length = 0 

10 - immediate Data Length = Length 24 MSB; CDB Length = 16 

+ Length(8 LSB) 

11 - Immediate Data Length = Length 16 MSB; CDB Length = 16 

+ Length(16 LSB) 
b5 (R) set when data is expected to flow from target to ini- 
tiator (read). 
bO-4 Reserved (should be 0) 
Byte 2 - SCSI flags 
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b7 (A) set to turn off Autosense for this command (see 

[SAM2]). 
b3-6 Reserved (should be 0) 
bO-2 used to indicate Task Attributes. 

Autosense refers to the automatic return of sense data to the ini- 
tiator in case a command did not complete successfully. If 
autosense is turned off, the initiator must explicitly request that 
sense data be sent to it after some command has completed with a 
CHECK CONDITION Status. 

3.2.2. Task Attributes 



The Task Attribute field (ATTR) can have one of the following 
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integer values (see [SAM2] for details): 



0 
1 
2 
3 
4 



Untagged 

Simple 

Ordered 

Head of Queue 

ACA 



3.2.3. Command Reference Number (CmdRN) enables ordered delivery 

3.2.4. ExpStatRN - Expected Status Reference Number 

Acknowledges status. Responses up to ExpStatRN -1 (mod 2**32) have 
been received. This number will also update the internal register. 
Values that do not appear as "increasing" will be ignored; this may 
be required when updates arrive out of order (they travel on dif- 
ferent TCP connections). 



3.2.5. Expected Data Transfer Length 

The Expected Data Transfer Length field states the number of bytes 
of data that the initiator expects will be sent for this (READ or 
WRITE) SCSI operation in SCSI Data packets. For a WRITE operation, 
the initiator uses this field to specify the number of bytes of 
data it expects to transfer for this operation in data packets (not 
counting data headers). For a READ operation, the initiator uses 
this field to specify the number of bytes of data it expects the 
target to transfer to the initiator (not counting data headers). 

If no data will be transferred in SCSI Data packets for this SCSI 
operation, this field should be set to 0. 
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Upon completion of a data transfer, the target will inform the ini- 
tiator of how many bytes were actually processed (sent or received) 
by the target. 

3.2.6. SCSI Command Descriptor Block (CDB) 

There are 16 bytes in the CDB field, designed to accommodate the 
largest currently defined CDB. if, in the future, larger CDBs are 
allowed, the spill -over of the CDB may extend beyond the 48-byte 
header. 

3.2.7. Command-Data 

Some SCSI commands require additional parameter data to accompany 
the SCSI command. This data may be placed beyond the 48-byte boun- 
dary of the iSCSl header. Alternatively user data can be placed in 
the same PDU (in both cases we talk about immediate data). 
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3.3. SCSI Response 



Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 0|7 654321 0|7 654321 0|7 654321 01 
4. + + + 4. 

01 Opcode (0x41) | Rsvd(O) |0|U| Reserved (0) | 
+ + + + + 

4 1 Length I 
+ + + + + 

8 1 Reserved (0) I 

+ + 

121 I 
+ + 4. + 4. 

161 initiator Task Tag I 

4. 4_ 4. 4. 4. 

201 Residual Count I 
4. 4. 4. 4. 4- 

24 1 StatRN I 

4. 4. 4. 4_ 4. 

281 ExpCmdRN I 

4. 4. 4_ 4. 4. 

321 MaxCmdRN I 
4. + + 4. 4. 

361 Command Status |i SCSI Status | Reserved (0) I 

4. 4. 4_ 4. 4. 

401 Res_len I Sense_len 

4. 4. 4_ 4. 4. 

44 1 Reserved (0) I 

+ 4. + 4_ 4. 

48/ Response and/or sense Data (optional) / 
+/ / 

4. 4. 4. 4. 4_ 



3.3.1. Flags 

Byte 1 
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bO (U) set for Residual Underflow, in this case, the Residual 
* Count indicates how many bytes were not transferred out of 

those expected to be transferred, 
bl (O) set for Residual Overflow, in this case, the Residual 
Count indicates how many bytes could not be transferred 
because the initiator's Expected Data Transfer Length was too 
smal 1 . 

b2-7 not used (should be set to 0). 
Bits 0 and 1 are mutually exclusive. 
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3.3-2. Residual Count 

The Residual Count field is valid only in case either the Residual 
Underflow bit or Residual Overflow bit is set. If neither bit is 
set, the Residual Count field should be 0. if the Residual Under- 
flow bit is set, the Residual Count indicates how many bytes were 
not transferred out of those expected to be transferred. If the 
Residual overflow bit is set, the Residual Count indicates how many 
bytes could not be transferred because the initiator's Expected 
Data Transfer Length was too small. 

3.3.3. Command Status 

The Command status field is used to report the SCSI status of the 
command (as specified in [SAM2]). 

3.3.4. iSCSl Status 

The iscsi status field is used to report the status of the command 
before it was sent by the target to the LUN. The values are given 
below. 

0 Good status 

1 iscsi check 

If the iscsi field is not 0 the command status will indicate CHECK 

CONDITION 

3.3.5. Res_len - Response length 

3.3-6. Sense_len - sense length 

3.3.7- Response or Sense Data 

If Autosense was not disabled in the originating CDB and the Com- 
mand status was check condition (0x02), then the Response Data 
field will contain sense data for the failed command. Some sense 
codes will relate to iSCSl check conditions (e.g. excessive number 
of outstanding commands, immediate data blocks too large etc.). If 
the Command status is Good (0x00) then the Response Data field will 
contain data from the data phase of the CDB. The Length parameter 
specifies the number of bytes in this field. If no error occurred, 
and no data is needed for the response to the SCSI Command the 
Length field is 0. Note that if the Command Status was CHECK CON- 
DITION but Autosense was disabled, then sense data must be expli- 
citly requested by the initiator with a new SCSI command. 
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3.3.8. StatRN - Status Reference Number 

StatRN is a reference number that the target iSCSl layer generates 
whenever it issues a response by incrementing an internal counter. 
A gap in StatRN indicates a lost status (possible due to connection 
failure) . 

3.3.9. ExpCmdRN - next expected CmdRN from this initiator 

This field will be used to update the internal register but values 
not between the current value of the ExpCmdRN and MaxCmdRN are 
ignored; this may be required when updates arrive out of order 
(they travel on different TCP connections) 

3.3.10. MaxCmdRN - maximum CmdRN acceptable from this initiator 

This field will be used to update the internal register but values 
not between the current value of the MaxCmdRN and ExpCmdRN are 
ignored; this may be required when updates arrive out of order 
(they travel on different TCP connections) 

Update order is MaxCmdRN, ExpCmdRN 
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3.4. NOP-Out Message 



Byte / 0 I 1 I 2 

/ I I 

17 654321 0|7 654321 0|7 6543210 
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+ + ^ + + 

01 Opcode (0x00) lP| Reserved (0) | Reserved (0) | 
+ ^ + + + 

41 Length I 
+ + + + + 

8/ Reserved (0) / 

+/ / 
+ ^ + + + 

281 ExpStatRN I 
+ + + + ^ 

32/ Reserved (0) / 

+/ / 
+ + + + + 

48 

3.4.1. P - poll bit 

Request a NOP-ln message 
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3.5. NOP-ln Message 



Byte / 0 I 1 

/ I 

17 654321 0|7 6543210 



7 6 5 4 3 2 1 0 



7 6 5 4 3 2 1 0 



01 Opcode (0x40) |P| Reserved (0) | Reserved(O) 
+ + + 

4 1 Length 



8/ Reserved (0) 



/ 
/ 



281 ExpCmdRN 
+ 

32 I MaxCmdRN 
+ 



-+- 



-+ 
I 

-+ 



— + 
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36/ Reserved (0) / 

+/ / 
+ + + 4. + 

48 

3.5.1. P - poll bit 

Request a NOP-Out message 
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3.6. Asynchronous Event 

An Asynchronous Event may be sent from the target to the initiator 
without corresponding to a particular command. The target specifies 
the status for the event and sense data. 

Byte / 0 I 1 I 2 I 3 I 
/ I I I I 
17 654321 0|7 654321 0|7 654321 0|7 654321 01 
+ + + 4. + 

01 Opcode (0x47) | Reserved (0) I 

4_ _,_ + 4. + 

4 1 Length I 

+ + + 4. + 

81 Logical unit Number (LUN) I 
+ + 
121 I 

+ + 4. 4. 4_ 

16/ Reserved (0) / 
+/ / 

+ 
I 

+ 
I 

+ 
I 

+ 
I 

+ 

/ 
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4_ 

24 1 StatRN 




-+ 


+ 


_4_ 


+ 

281 ExpCmdRN 




-+ 


4. 


_4. 


+ 

32 1 MaxCmdRN 




-+ 


4. 


-4. 


+ 

36 1 SCSI Event 


Ind 


-+ 

liscsi 


4. 

Event lnd| Reserved (0) 


_4_ 


+ 

40/ Reserved 


(0) 


-+ 


4. 


-4. 
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/ / 
+ + + + + 

48/ Sense Data / 

+/ / 
+ + + + + 



3.6.1. iSCSI Event 

Some Asynchronous Events are strictly related to iSCSl while others 
are related to SAM-2. The codes returned for iSCSl Asynchronous 
Events are: 

2 Target is being reset. 
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3.6.2. SCSI Event Indicator 

The following values are defined, (see [SAM2] for details.) 

1 An error condition was encountered after command comple- 
tion. 

2 A newly initialized device is available. 

3 Some other type of unit attention condition has occurred. 

4 An asynchronous event has occurred. 

Sense Data accompanying the report identifies the condition. The 
Length parameter is set to the length of the Sense Data. 
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3.7. SCSI Task Management Command 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 017 654321 0|7 654321 0|7 654321 Oi 
^ + + + + 

01 Opcode (0x02) | Function | Reserved (0) I 
^ + + + + 

4 1 Length I 

+ + + + + 

81 Logical Unit Number (LUN) I 

+ + 

121 I 
+ ^ + + + 

161 Initiator Task Tag I 
+ + + + + 

201 Referenced Task Tag or Reserved (0) I 
+ + + + + 

241 CmdRN I 

+ 4. + + + 

281 ExpStatRN I 

+ ^ + + + 

32/ Reserved (0) / 

+/ / 
+ ^ + + + 

48 

3.7.1. Function 

The Task Management functions provide an initiator with a way to 
explicitly control the execution of one or more Tasks. The Task 
Management functions are summarized as follows (for a more detailed 
description see the [SAM2] document): 

1 Abort Task — aborts the task identified by the Referenced 
Task Tag field. 

2 Abort Task Set — aborts all Tasks issued by this initia- 
tor on the Logical Unit. 

3 Clear ACA — clears the Auto Contingent Allegiance condi- 
tion. 

4 Clear Task Set — Aborts all Tasks (from all initiators) 
for the Logical Unit. 

5 Logical umt Reset. 

6 Target Reset. 

For the functions above except <Target Reset>, a SCSI Task Manage- 
ment Response is returned, using the Initiator Task Tag to identify 
the operation for which it is responding. For the <Target Reset> 



sat ran, smith, Sapuntzakis, Meth [Page 23] 

□ 

iSCSI June 2000 

Page 19 



draft-sat ran-i scsi -01. txt 



function, the target cancels all pendinq operations. The target may 
send an Asynchronous Event to all attached initiators notifying 
them that the target is being reset. The target then closes all of 
its TCP connections to all initiators (all sessions are ter- 
minated) . 
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3.8. SCSI Task Management Response 



Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 0|7 654321 0|7 654321 0|7 654321 01 
4. + 4. 4. + 

0| Opcode (0x42) | Response | Reserved (0) I 

4. 4_ 4. 4. 4- 

41 Length I 
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^ 

81 Logical Unit 




Number (LUN) 


-+ 


+ 


4- 

121 








16 1 Initiator Task Tag 


-+ 


+ 


■r 

201 Reserved (0) 




-+ 


+ 


+ 

241 StatRN 





-+ 


+ 


+ 

281 ExpCmdRN 


--+ 


-+ 


+ 


+ 

32 1 MaxCmdRN 


.-4. 


-+ 


4. 


4. 

361 Response 




1 Reserved (0) 


-+ 


+ 


4. 

40/ Reserved (0) 

+/ 

+ 


--+ 




T 

- + 


r ~ — 
_|_ 



48 



For the functions <Abort Task, Abort Task set, Clear aca, clear 
Task Set, Logical unit reset>, the target performs the requested 
Task Management function and sends a SCSI Task Management Response 
back to the initiator. The target includes all of the information 
the initiator provided in the SCSI Task Management Message, so the 
initiator can Know exactly which SCSI Task Management Messaqe was 
serviced. In addition, the target provides a Response which may 
take on the following values: 

0 Function Complete 

1 Function Rejected 

For the <Target Reset> function, the target cancels all pending 
operations. The target may send an Asynchronous Event to all 
attached initiators notifying them that the target is being reset. 
The target then closes all of its TCP connections to all initiators 
(terminates all sessions). 
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3.9. Ready To Transfer (RTT) 

When an initiator has submitted a SCSI Command with data passing 
from the initiator to the target (write), the target may specify 
which blocks of data it is ready to receive. In general, the target 
may request that the data blocks be delivered in whatever order is 
convenient for the target at that particular instant. This informa- 
tion is passed from the target to the initiator in the Ready To 
Transfer (RTT) message. In order to allow write operations without 
RTT, the initiator and target must have agreed to do so by both 
sending the UseRTTino key-pair attribute to each other (either dur- 
ing Login or through the Text Command/Response mechanism). 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 0|7 654321 0|7 654321 0|7 654321 01 
+ 4. + 4. 4. 

I 

-+ 
I 

4. 4. 4. + 4. 

81 Reserved (0) I 
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4. 

Opcode (0x46) | Reserved (0) 


-+ 


4. 


4. 

Length 


-+ 

-+ 


4. 
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+ + 

16 1 Initiator Task Tag 


-+ 


^ 


+ + 

201 Desired Data Transfer Length 


-+ 


+ 


+ + 

24 1 Buffer Offset 


-+ 


+ 


+ + 

281 ExpCmdRN 


-+ 


+ 


+ + 

321 MaxCmdRN 


-+ 


+ 


+ + 

^fil mp1" Tr';in<;"Fpr Tan 


-+ 


4. 


+ ^ 

40/ Reserved (0) 
+/ 


-+ 


+ 


+ ^ 

48 


-+ 


+ 



3.9.1. Desired Data Transfer Length and Buffer Offset 

The target specifies how many bytes it wants the initiator to send 
as a result of this rtt message. The target may request the data 
from the initiator in several chunks, not necessarily in the 
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original order of the data. The target, therefore, also specifies 
a Buffer offset indicating the point at which the data transfer 
should begin, relative to the beginning of the total data transfer. 

3.9-2. Target Transfer Tag 

The target assigns its own tag to each RTT request that it sends to 
the initiator. This can be used by the target to easily identify 
data it receives. 
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3.10. SCSI Data 

The typical data transfer specifies the length of the data payload, 
the Transfer Tag provided by the receiver for this data transfer, 
and a buffer offset. The typical SCSI Data packet for write (from 
initiator to target) has the following format: 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321 0|7 654321 0!7 654321 0|7 654321 01 
+ + + + + 

01 Opcode (0x05) | Reserved (0) I 
+ + + + + 

4 1 Length I 
+ + + + + 

81 Buffer offset I 
+ + + + + 

12 1 Transfer Tag I 
+ ^ ^ + + 

161 Initiator Task Tag I 
4. + + + + 

201 Reserved (0) I 

+/ / 
+ 4. + + + 

281 CmdRN I 
4. 4. + + + 

281 ExpStatRN I 

+ + + 4. 4. 

32/ Reserved (0) / 
+/ / 

4_ ^ 4. 4. + 

48/ Payload / 

+/ / 
4. 4. 4. 4. 4. 

The typical SCSI Data packet for READ (from target to initiator) 
has the following format: 
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Byte / 0 I 1 

/ I 

17 6 5 4 3 2 1 0|7 6 5 4 3'2 1 0 



76543210 



7 6 5 4 3 2 1 0 



+ + 

01 opcode (0x45) | (0) 


+- 

Islolul 


Reserved 


(0) 


-.4. 


+ + 

4| Length 


+- 






_+ 


+ + 

81 Buffer Offset 


+- 









+ + 

12 1 Transfer Tag 


+- 









+ _ ^ 

1d| Initiator Task Tag 


+- 






_+ 


+ 4. 

201 Residual Count 


+- 






_+ 

_+ ■ 


+ + 

241 StatRN 


+- 








+ + 

281 ExpCmdRN 


+- 






_+ 


+ + 

321 MaxCmdRN 


+- 









^ + 

361 Command Status |i SCSI 


+- 

status 1 


Reserved 


(0) 


_+ 


+ + 

40/ Reserved (0) 
+/ 


+- 






_+ 


+ ^ 

48/ Payload 
+/ 

+ ^ 


+- 






_+ 


+- 










3.10.1. Length 

The length field specifies the total number of bytes in the follow- 
ing payload. 

3.10.2. Transfer Tag 

The Transfer Tag identifies the target or initiator entity to which 
this data transfer relates. When the transfer is from the target 
to the initiator, the Transfer Tag is the initiator Task Tag that 
was sent with the SCSI command, when the transfer is from the ini- 
tiator to the target, the Transfer Tag is the Target Transfer Tag 
when RTT is enabled, or the initiator Task Tag when RTT is dis- 
abled. 
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3.10.3. Buffer offset 
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The Buffer Offset field contains the offset of the following data 
against the complete data transfer. The sum of the buffer offset 
and length should not exceed the expected transfer length for the 
command . 

3.10-4. Flags 

The last SCSI Data packet sent from a target to an initiator for a 
particular SCSI command that completed successfully may optionally 
also contain the Command Status for the data transfer. In this 
case Sense Data cannot be sent together with the Command Status. 
If the command completed with an error, then the response and sense 
data must be sent in a SCSI Response packet and must not be sent in 
a SCSI Data packet. 
Byte 1 

bO-1 as in an ordinary SCSI Response 

b2 (S) set to indicate that the Command Status field con- 
tains status. 

b3-7 not used (should be set to 0). 
If the (S) bit is set, then there is meaning to the extra fields in 
the SCSI Data packet (StatRN, Command Status, Residual Count). 

3.10.5. Packet numbering (CmdRN and StatRN) 

On both inbound and outbound data the source may decide to number 
(sequence) the data packets to enable shorter recovery on connec- 
tion failure, in case the source numbers data packets the destina- 
tion is required to acknowledge them the same way it does with com- 
mand and status packets - i.e. specifying the next expected packet. 
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3.11. Text Command 

The Text Command is provided to allow the exchange of information 
and for future extensions, it permits the initiator to inform a 
target of its capabilities or to request some special operations. 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 
17 654321017 654321 0|7 654321 0|7 654321 01 
+ ^ + + 4. 

01 opcode (0x04) | Reserved (0) I 
+ ^ + + + 

4 1 Length I 
+ + + + 
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8/ Reserved (0) / 

+/ / 
+ + + + + 

161 Initiator Task Tag I 
+ + + + + 

201 Reserved (0) I 
_,. + + + 4. 

241 CmdRN I 
+ + + + 4. 

281 ExpStatRN I 
4. 4. 4. + 4. 

32/ Reserved (0) / 

+/ / 
+ 4. + + 4. 

48/ Text / 

+/ / 
4. 4. + 4. 4- 



3.11.1. Length 

The length, in bytes, of the Text field. 

3.11.2. Initiator Task Tag 

The initiator assigned identifier for this Text Command. 

3.11.3. Text 

The initiator sends the target a set of key rvalue pairs in UTF-8 
Unicode format. The key and value are separated by a (Ox3a) 
delimiter. Many key: value pairs can be included in the Text block 
by separating them with null ' ' (0x00) delimiters. Some basic 
key:value pairs are described in Appendix B. The target responds 
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by sending its response back to the initiator. The target and ini- 
tiator can then perform some advanced operations based on their 
common capabilities. 

Manufacturers may introduce new keys by prefixing them with their 
(reversed) domain name, for example, 

com . f 00 . ba r . do.somethi ng : 0000000000000003 

Any key that the target does not understand may be ignored without 
affecting basic function. Once the target has processed all the 
key: value pairs, it responds with the Text Response command, list- 
ing the parameters that it supports. It is recommended that Text 
operations that will take a long time should be placed in their own 
Text command, if the Text Response does not contain a key that was 
requested, the initiator must assume that the key was not under- 
stood by the target. 
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3.12. Text Response 

The Text Response message contains the responses of the target to 
the initiator's Text Command. The format of the Text field matches 
that of the Text Command. 



Byte / 0 I 1 

/ I 

17 654321 0|7 6543210 



7 6 5 4 3 2 1 0 



76543210 



01 Opcode (0x44) | Reserved (0) 
+ + +. 



I 

-+ 



4 1 Length 



+- 



-+- 



8/ Reserved (0) 



/ 
/ 
-+ 

I 

-+ 
I 



161 Initiator Task Tag 

^ + 

201 Reserved (0) 



24 1 StatRN 
+- 



I 

-+ 



281 ExpCmdRN 



321 MaxCmdRN 
+ 

36/ Reserved (0) 



I 

-+ 
/ 
/ 

-+ 

/ 
/ 
-+ 



48/ Text Response 
+/ 

4. +. 



3.12.1. Length 



The length, in bytes, of the Text Response field. 
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3.12.2, Initiator Task Tag 

The Initiator Task Tag matches the tag used in the initial Text 
Command and is used by the initiator to relate the Text Commands 
with the appropriate Text Responses. 

3.12.3. Text Response 

The Text Response field contains responses in the same key: value 
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format as the Text Command. Appendix B lists some basic Text Com- 
mands and their Responses, if the Text Response does not contain a 
key that was requested, the initiator must assume that the key was 
not understood by the target. 



Page 28 



draft-satran-i scsi -01. txt 

Sat ran, Smith, Sapuntzakis, Meth [Page 34] 

□ 

iSCSI June 2000 

3.13. Login Command 

After establishing a TCP connection between an initiator and a tar- 
get, the initiator should issue a Login Command to gain further 
access to the target's resources. 



Byte / 0 I 1 I 2 

/ I I 

|7 654321 0|7 654321 0|7 6543210 



3 I 
I 

7 6 5 4 3 2 1 01 



0| Opcode (0x03) | Login Type | Reserved (0) I 
+ + + + ^ 

4 1 Length I 

+ 4. + + 4. 

81 CID I RecoverCiD or 0 I 
4. 4. + + + 

121 Reserved (0) I 
4. 4. 4. 4. 4. 

161 ISID ITSID I 
4. 4. 4. 4. 4. 

24 1 initCmdRN or 0 I 

4. 4. 4. 4. 4. 

28/ Reserved (0) / 

+/ / 

+ + + + + 

48/ Login Parameters in Text Command Format / 

+/ / 
4. 4. 4. 4. 4. 

3.13.1. Login Type 

Five types of logins are supported: clear text, RSA (Rivest Shamir 
Adelman) one way (to authenticate the client only), RSA two way (to 
authenticate both the server and the client), and implicit (in 
which a separate security protocol provides the credentials). The 
parameter 'Access-ID" [AC] is used to identify the specific initia- 
tor. 

0 no authentication 

1 implicit 

2 clear text password authentication 

3 RSA 1 way 

4 RSA 2 way 



3.13.2. CID 

A unique id for this connection within the session 
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3 . 13 . 3 . RecoverCiD 

For a connection used to recover a lost TCP connection the initia- 
tor provides the CID of the failed connection. A simple target may 
reject recovery, in this case the initiator will terminate all out- 
standing commands with a check condition. Further action is up to 
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the initiator (implementation dependent). 

3.13.4. Login Parameters 

The initiator may provide some basic parameters in order to enable 
the target to determine if the initiator may in fact use the 
target's resources. The format of the parameters is as specified 
for the Text Command. Targets may require keys to indicate the 
Domain Name of the initiator and the target, and perhaps also an 
Authenticator key. The initiator may also provide additional 
parameters to the target in Text Command format, if the initiator 
so desires. Keys and their explanations are listed in Appendix B. 
Whenever desired an initiator will identify its view of the target 
as in: 

Target : <domai n-name> [/modi f i er] [ : port! 

implying that the target is known as: 

scsi : //<domai n-name> [/modi f i er] 

and it should be connected through port "port" (the default, well 
known port, has an icann defined value of xx) . initiators can use 
the same type of naming implying machine and an optional principal 
(e.g. operating system image) as in: 

Ini ti ator : <domai n-name> [/modi f i er] 

implying that the initiator is known as: 

i SCSI : //<domai n-name> [/modi f i er] 



Thus the parameters passed for a clear-text password authentication 
are: 

Ini ti ator : <domai n-name> [/modi f i er] 
Target : <domai n-name> [/modi f i er] 
Autnenti cator : open-sesame 
Access-ID: value 

The modifier iscsl-SYS is reserved for administrative functions. 
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ISID and TSID form collectively the SSID (session id). A TSID of 0 
indicates a leading connection. Only a leading connection login can 
carry session specific parameters, e.g. max-connections-requested, 
the maximum immediate data length requested, etc.. 

3.13.5. initCmdRN 

IS significant only if TSID is 0 and indicates the starting Command 
reference number for this session; it should be 0 for all other 
instances. 

3.13.6. Clear-text login 

In clear text login, both the Access ID and the secret are not 
encrypted, and the target will either accept or reject the login. 

3.13.7. RSA One Way Authentication 
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In RSA one way authorization, the initiator logs-on specifying the 
Access-ID. The target responds with a randomly generated string 
(not to exceed 64 Bytes) that has been encrypted using the 
initiator's RSA public key, which is passed as the 
"Authentication-lnitiator-challenge" parameter. The initiator 
decrypts the string using its private key and returns the response 
as "Authentication-Initiator-Response" parameter. The target 
either accepts or rejects the login. 

3.13.8. RSA Two Way authentication 

In RSA two way authentication, the initiator generates a random 
string (not to exceed 64 bytes) that is encrypted with the RSA pub- 
lic key of the target- This string is sent to the target as the 
"Authenticator-Target-challenge" parameter- The target decrypts 
this parameters and sends it back as the "Authentication-Target- 
Response", as well as generating an "Authentication-lnitiator- 
Challenge" parameter as outlined above 

3.13.9- implicit authentication 

In implicit authentication, both the Access ID and any authentica- 
tion is performed by the security protocol, and no explicit Access 
ID or authentication information is exchanged during the login pro- 
cess. 

3.13.10. TLS Session 

The initiator can request a TLS session by entering a single text 
parameter of "Encrypted Session" set to the value of "TLS 1.0"- 
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After the target has acknowledged the login command, a TLS 1.0 ses- 
sion is started on the same connection. Authentication is then 
performed using a second login command in clear text mode. The use 
of any specific set of certificates is not controlled by this 
specification. 
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3.14. Login Response 

The target responds to the Login Command with a Login Response. It 
is sufficient for the target to respond with a Status indicating 
that the Login is accepted, in fact, the target may completely 
ignore the parameters that were sent to it and may provide service 
to any initiator that connects to it. The target may also return 
parameters using the format of the Text Response opcode, if it so 
desires. In particular, the target may want to provide its Authen- 
ticator key, so that the initiator can be sure that it is in fact 
talking with the correct target. 

Byte / 0 I 1 I 2 I 3 I 

/ I I I I 

17 654321 0|7 654321 0|7 654321 0|7 654321 01 

4. + + 4. 4. 

0| Opcode (0x43) | Reserved (0) I 

+ 4. 4. 4. ^ 

4 1 Length I 

+ 4_ 4_ 4. 4. 

8/ Reserved (0) / 
+/ / 

4. 4_ 4_ 4. + 

161 ISID I TSID I 
4. 4. + 4. 4. 

201 Reserved (0) 1 
+ + + + + 

241 initStatRN or 0 I 
+ 4. 4. 4. 4. 

281 ExpCmdRN I 
+ 4. 4. 4. 4. 

321 MaxCmdRN I 
4. 4. 4. 4- + 

361 Status I Reserved (0) I 
+ 4. 4. 4. 4. 

40/ Reserved (0) / 

+/ / 
+ 4. 4. 4. 4. 

48/ Login Parameters in Text Command Format / 

+/ / 
4. 4. ^ 4. 4. 
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3.'l4.1. initStatRN 

IS significant only if TSID is 0 and indicates the starting status 
reference number for this session; it should be 0 for all other 
instances. 
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3.14.2. Status 

The Status returned in a Login Response is one of the following: 

0 accept login (will now accept SCSI commands) 

1 reject login 

2 additional authentication required 

3 reject recovery 

In the case that the Status is "accept login" the initiator may 
proceed to issue SCSI commands, in the case that the status is 

reject login" the initiator should immediately close down its end 
of the TCP connection, thus freeing up the target's port for some 
other connection. The target also has the option of immediately 
closing down its end of the TCP connection. In the case that the 
Status is "additional authentication required" the initiator must 
provide additional authentication information by issuing the Text 
Command with the appropriate key: value pairs; this may Be required 
if the authentication method is based on a challenge/response algo- 
rithm. Upon receipt of the necessary authentication, the target 
will issue a Login Response with the "accept login" status. SCSI 
Commands will not be accepted until the target provides a Login 
Response with the "accept login" status. The TSID is an initiator 
identifying tag set by the target. A 0 in the returned TSID indi- 
cates that either the target supports only a single connection or 
that the ISID has already been used as a leading ISID. In both 
cases the target is rejecting the login. 
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Byte / 0 I 1 I 2 I 3 I 
/ I I I I 
17 654321 0|7 654321 0|7 654321 017 654321 01 
+ + ^ ^ + 

01 Opcode (0x09) | Reserved (0) I 
+ + + + + 

4 1 Length I 
^ + + ^ + 

8/ Reserved (0) / 

+/ / 
+ + 4. , + + 

16 1 initiator Task Tag I 
+ + + + + 

201 Reserved (0) I 
+ + + + + 

24 1 CmdRN I 
+ + + + + 

281 ExpStatRN I 
+ + + + + 

32/ Reserved (0) / 

+/ / 
+ ^ + + + 

48/ Ping Data (optional) / 

+/ / 
+ ^ + + 4. 

The Ping Command can be used to verify that a connection is still 
active and all it's components are operational; unlike the NOP mes- 
sage Ping has a Task Tag and can be delivered in order. It may be 
useful in the case where an initiator has been waiting a long time 
for the response to some command, and the initiator suspects that 
there is some problem with the connection. When a target receives 
the Ping Command, it should respond with a Ping Response, duplicat- 
ing as much of the data as possible that was provided in the Ping 
Command (if such data was present). If the initiator does not 
receive the Ping Response within some period of time (determined by 
the initiator), or if the data returned by the Ping Response is 
different from the data that was in the Pinq Command, the initiator 
may conclude that there is a problem with the connection. The ini- 
tiator will then close the connection and may try to establish a 
new connection. 

3.15.1. Length 

The length of the optional Ping Data, 
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3.15.2. Initiator Task Tag 

An initiator assigned identifier for the operation. 
3.15-3. Ping Data 

Binary data that will be reflected in the Ping Response. 
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3.16. Ping Response 



Byte / 0 

17 6 5 4 3 2 10 



1 I 2 

I 

7654321 0|7 6543210 



7 6 5 4 3 2 1 0 



0| Opcode (0x49) | Reserved (0) 
+ +- 



I 

-+ 



4 1 Length 



8/ Reserved (0) 



/ 
/ 
-+ 

I 

-+ 
I 

-+ 
I 

-+ 
I 

-+ 



161 Initiator Task Tag 
+ + 

20 1 Reserved (0) 



24 1 StatRN 
+ 

281 ExpCmdRN 
+ 



— + 
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321 MaxCmdRN | 
+ + ^ + ^ 

36/ Reserved (0) / 

+/ / 
+ + ^ + + 

48/ Return Ping Data / 

+/ / 
+ + ^ + + 



When a target receives the Ping command, it should respond with a 
Ping Response, duplicating the data and initiator Task Tag that was 
provided in the Ping Command, if present. 
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3.17. Map Command 



Byte / 0 I 1 

/ I 

17 654321 0|7 6543210 



76543210 



76543210 



Oi Opcode (OxOa) | Function 



I Reserved (0) 
_+ 



I 

-+ 
I 

-+ 
I 

+ 



4 1 Length 



81 Reserved (0) 
+ 
121 



161 Initiator Task Tag 
+ + 

20 1 Reserved (0) 



24 1 CmdRN 

+ 

281 ExpStatRN 



32/ Reserved (0) 

+/ 



/ 
/ 



481 Descriptor Type 
+ ^. 

52/ Descriptor 

+/ 

4. ^_ 



I Descriptor Length 
.+ ^ — 



-+ 
/ 
/ 



+ 

I Descriptor Type 



— 4. ^ — 

I Descriptor Length 
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+ + 4. + + 

/ Descriptor / 

+/ / 

+ + 4. _|. 4_ 



or 
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+ + + 4_ + 

481 8 byte Descriptor I 

+ 1 I 
+ 4. + + 4. 

+ 4. + + 4. 

N I 8 byte Descriptor I 

+ 1 I 
+ 4. + 4. _|. 



The mapping command enables the initiator to map iSCSl specific 
addresses and access control information into formats compliant 
with the SCSI command standards (e.g., [SPC-2]). 

3.17.1. Function 

Two functions are required for mapping: 

1 Map - given an address or access control information pro- 
vide the 8 byte SCSI compliant address reference 

0 unmap Given a SCSI compliant address reference remove the 
mapping associated with it. 

Address/access control descriptors follow the header. For the map 
function the following descriptor types are defined: 

0 IP Version 4 TCP address followed by a TAN( Target 
Acquired Name); length should be 6 + the view length + 1 

1 IP Version 6 TCP address followed by a TAN; length should 
be 18 bytes + the view length -f 1 

2 iSCSl URL (domain name terminated with null followed by a 
TAN followed by null) 

3 FC address & port - in case access control is based on 
transport ID 

4 access proxy token 

Details for 3 & 4 have to be coordinated with TlO 

For the unmap function the descriptors are standard 8 byte SRAs 
(SCSI Reference Address) 
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3.18. Map Response 



Byte / 0 I 1 I 2 

/ I I 

17 654321 0|7 654321 0|7 6543210 



7 6 5 4 3 2 1 0 



01 Opcode (0x4a) | Reserved (0) I 
+ + + + + 

4 1 Length I 

+ + + + 4. 

81 Reserved (0) I 
+ + 



121 



161 Initiator Task Tag I 
+ + + ^ + 

201 Reserved (0) I 
+ ^ ^ + + 

24 1 StatRN t 
4. + ^ + 4. 

281 ExpCmdRN I 



32 I MaxCmdRN 

4. + 



361 Response | Reserved (0) 



40/ Reserved (0) / 

+/ / 
+ + ^ 4. + 

48 



The target provides a Response which may take on the following 
values: 

0 Function Complete 

1 Map Function Rejected - Bad Descriptors 

2 Map Function Rejected - too many descriptors 

3 Unmap Function Rejected - Bad Descriptor 

If the Response to a map is function complete the data following 
the header contains the SRAs to be used in third party commands; 
each SRA matches a descriptor in the Map command. 
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3.19. Third Party Commands 
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There are some third-party SCSI commands, such as (EXTENDED) COPY 
and COMPARE, that involve more than one target, in its most general 
form those commands involve the "original target" called the COPY- 
Manager and a (variable) number of other machines called source and 
destination. The whole operation is described by one "master CDB" 
delivered to the Copy manager and a series of descriptor blocks; 
each descriptor block addresses a source and destination target and 
LU and a description of the work to be done in terms of blocks or 
bytes as required by the device types. The relevant SCSI standards 
do not require full support of the (EXTENDED) COPY or COMPARE nor 
do they provide a detailed execution model, we will assume, in the 
spirit of [SPC-2] that a COPY manager will read data from a source 
and write them to a destination. 

To address them an iSCSi COPY manager will use information provided 
to it through map commands and the SRAs and flags provided in the 
descriptors - allowing for iscsi and FC sources and destinations. 

Enabling a FC COPY manager to support iscsi sources and destina- 
tions is subject to coordination with TlO. 
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3.20. opcode Not Understood 

Byte / 0 I 1 I 2 

/ I I 
17 654321 017 654321 0|7 654321076543210 
4. + + 

0| opcode (0x48) | Reserved (0) 

^ + ^ 

4 1 Length 



8/ Reserved (0) / 

+/ / 
4. + ^ + ^ 
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48/ Header of Bad Message / 

+/ / 
^ + ^ ^ _^ 

96 

It may happen that a target receives a message with an Opcode that 
it doesn't recognize. This may occur because of a new version of 
the protocol that defines a new Opcode, or because of some corrup- 
tion of a message header. The target returns the header of the 
message with the unrecognized opcode as the data of the response. 
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4. iSCSI Error Handling 

4.1. communications Errors 

For any outstanding SCSI command, it is assumed that iSCSl in con- 
junction with SCSI at the initiator is able to keep enough informa- 
tion to be able to rebuild the command PDU, that outgoing data is 
available (in host memory) for retransmission while the command is 
outstanding. It is also assumed that at a target iscsi and special- 
ized TCP implementations are able to recover unacknowledged data 
packets from a closing connection or, alternatively the target has 
means to re-read data from a device-server. It is further assumed 
that a target will keep the "status & sense" for commands it has 
executed while the total number of outstanding commands and exe- 
cuted commands does not exceed its limit. A target will sequen- 
tially number the delivered responses and thus enable initiators to 
tell when a response is missing and which response is missing. 

Under those conditions, iscsi will be able to keep a session in 
operation provided that it is able to keep/establish at least one 
TCP connection between the initiator and target in a timely 
fashion. Unfortunately the maximum admissible recovery time is a 
function of the target and for some devices and communications net- 
works recovery may be complex and may percolate to upper software 
layers. It is assumed that targets and/or initiators will recog- 
nize a failing connection by either transport level means (TCP) or 
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by a gap in the command or response stream that does not get filled 
for a long time, or by a failing iscsi ping (the later should be 
used periodically by highly reliable implementations). The 
recovery involves the following steps: 

-abort offending TCP connection(s) (target & initiator) and 

recover at target all unacknowledged read-data 
-create one or more new TCP connections (within the same ses- 
sion) and associate all outstanding commands from the failed 
connection to the new connection at both initiator and target, 
-the initiator will reissue all outstanding commands with their 
original Initiator Task Tag and their original CmdRN if they 
are not acknowledged yet or a new CmdRN if they where ack- 
nowledged; in any case the retry (x) flag in the command PDU 
will be set 

-upon receiving the new/retry commands the target will resume 
command execution; for write commands it means requesting data 
retransmission through RTT, for reads retransmitting recovered 
data and for "terminated" commands retransmitting the status & 
sense while retaining the original StatRN. If data recovery is 
not possible the target will either provide data from the 
media or redo the operation (if the operation is not idempo- 
tent the device server may fail the operation). 
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4.2. Protocol Errors 

The authors recognize that mapping framed messages over a "stream" 
connection (like TCP) makes the proposed mechanisms vulnerable to 
simple software framing errors and introducing framing mechanisms 
may be onerous for performance and bandwidth. Command reference 
numbers and the above mechanisms for connection drop and reestab- 
lishment will help handle this type of mapping errors. 

4.3. Session Errors 

If all the connections of a session fail and can't be reestablished 
in a short time or if initiators detect protocol errors repeatedly 
an initiator may choose to terminate a session and establish a new 
session (indicating old session termination?), it will terminate 
all outstanding requests with an iSCSl error indication before ini- 
tiating a new session. A target that detects one of the above 
errors will take the following actions: 

- Reset the TCP connections (close the session). 

- Abort all Tasks in the task set for the corresponding initia- 
tor. 
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5. Notes to Implementers 

This section notes some of the performance and reliability con- 
siderations of the iscsi protocol. This protocol was designed to 
efficient silicon and software implementations. The iSCSl tag 
mechanism was designed to enable RD^4A at the iSCSl level or lower. 

5.1. Small TCP Segments 

It is recommended that TCP segments be limited in size to no more 
than 8k bytes. One reason we recommend small segments is to allow a 
stronger type of checksum, possibly utilizing CRC, which is practi- 
cal only for smaller segments. 

5.2. Multiple Network Adapters 

The iSCSl protocol allows multiple connections, not all of which 
need go over the same network adapter. If multiple network connec- 
tions are to be utilized with hardware support, the iscsi protocol 
command-data-status allegiance to one TCP connection insure that 
there is no need to replicate information across network adapters 
or otherwise require them to cooperate. 

5.3. Autosense 

Autosense refers to the automatic return of sense data to the ini- 
tiator in case a command did not complete successfully. If 
autosense is turned off, the initiator miist explicitly request that 
sense data be sent to it after some command has completed with a 
CHECK CONDITION Status. The default for iscsi is to work with 
Autosense enabled. Note that even if a SCSI target/LUN does not 
support Autosense, it may still be possible for iSCSl to work with 
Autosense. This can be accomplished as follows. Whenever a CHECK 
CONDITION status is about to be returned, the iscsi component on 
the target immediately queries the target/LUN for the sense data, 
iscsi can then return the sense data to the initiator together with 
the CHECK CONDITION Status. It is not necessary for iSCSl to wait 
for the initiator to explicitly request the sense data; the target 
iscsi code can perform this operation automatically, even for 
devices/LUNs that do not ordinarily provide automatic sense data. 

5.4. TCP Connection Options 

Some targets may want to inform (or negotiate with) an initiator 
concerning some parameters related to bandwidth, Quality of Ser- 
vice, or some other available features on its various network con- 
nections. These are exchanged between the initiator and the target 
using Text Commands and Responses. 
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6. security Considerations 



6.1. Data Integrity 

we assume that end-to-end data integrity can be assured by TCP, by 
adding a more powerful checksum option whenever this is considered 
important, or leaving the standard checksum for those applications 
in which data integrity is not of utmost importance. 

6.2. Network operations and the Threat Model 

Historically, native storage systems have not had to consider secu- 
rity due to the fact that their environments offered minimal secu- 
rity risks- That is, these environments consisted of storage dev- 
ices either directly attached to hosts or connected via a subnet 
distinctly separate from the communications network. The use of 
storage protocols, such as SCSI, over IP networks requires that 
security concerns be addressed. 

6.2.1. Threat Model 

Attacks fall into three main areas; passive, active, and denial of 
service. 

6.2.1.1. Passive Attacks 

In general, data transfers will be made through a switched fabric, 
making sniffing difficult. Also, the nature of the data (block 
transfers), even if sniffed, would not necessarily be readily 
understandable to the attacker. That being said, a determined 
attacker could, by capturing of content and analyzing traffic over 
time, could replicate enough of a drive to make the captured data 
meaningful. Certain storage operations which are mostly uni- 
directional, such as writing to a tape or reading from a CD-ROM, 
are even more susceptible to passive attacks since the listener 
will be able to replicate most if not all of the operation. 

Passive attacks by traffic analysis alone is deemed out of scope 
since it is unlikely that the listener will be able to guess any 
pertinent information without knowing the content of the messages. 
It is also out of scope to detect passive attacks. The protocol 
must be able to prevent passive attacks by masking the contents of 
messages through some form of encryption. 

Finally, it is assumed that a strong authentication mechanism will 
be necessary. Therefore, any long-lived passwords or private keys 
must never be sent in the clear. 
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6.2.1.2. Active Attacks 

whereas passive attacks involve sniffing, active attacks will gen- 
erally involve SPOOFING. If an attacker can successfully masquerade 
as a client, he will have total read/write access to those storage 
resources assigned to that client. Spoofing as a server is more 
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difficult, since many operations involve client reads of some 
expected or otherwise understandable data. 

Most likely, many of the sessions will be long-lived. This feature 
has a dual effect of making these sessions more vulnerable to 
attack (hijacking TCP connections, cryptographic attacks), while at 
the same time providing mechanisms to detect attacks. An attempt to 
open a session while one is already active can be treated as a pos- 
sible attack. Both the transport and session layer protocols will 
have sequencing that would need to be adhered to by the attacker to 
avoid generating errors that could also be treated as a possible 
attack. 

Message modification can be a significant threat to an environment 
reliant on the integrity of the data. Message replay, insertion, or 
deletion will generally produce errors (such as data 
overruns/underruns) that can be recovered successfully, they can 
have the effect of reducing performance, and as such can act as a 
denial of service. It is possible that an attacker can modify a 
message in such a way the session becomes out of sync, resulting in 
a tear down of the session, 

6.2.2. Security Model 

6.2.2.1. No Security 

This mode does not authenticate nor does it encrypt data. This mode 
should only be used in environments where there is minimal security 
risk and little chance for configuration errors. 

6.2.2.2. End-to-End Authentication 

This mode protects against an unauthorized access to storage 
resources either through an active attack (spoofing) or configura- 
tion errors. Once the client is authenticated, all messages are 
sent and received in the clear. This mode should only be used when 
there is minimal risk to man-in-the-middle attacks, eavesdropping, 
message insertion, deletion, and modification. For example, this 
mode can be used when iPsec is used in security gateways. 
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6.2.2.3. Encryption 

This mode provides for the end-to-end encryption (e.g. iPsec) . In 
addition to authenticating the client, it provides end-to-end data 
integrity and protects against man-in-the-middle attacks, eaves- 
dropping, message insertion, deletion, and modification. 

A connection or multiple connections can be protected end-to-end by 
using iPSec . In this case, the initiator must use the "Implicit 
Authentication" parameter to indicate that IPSec should be used to 
specify the Access id and perform authentication. 

6.2.3. Other Considerations 

Due to long-lived sessions, is there a need for periodic authenti- 
cation after the session is established? For example, should the 
client be challenged during key-alive exchanges in addition to 
login? 
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Due to long-lived sessions with encryption, is there a higher level 
of vulnerability to cryptographic attacks? 



6.3. Login Process 

In some environments, a target will not be interested in authenti- 
cating the initiator. In this case, the target can simply ignore 
some or all of the parameters sent in a Login Command, and the tar- 
get can simply reply with a basic Login Response indicating a suc- 
cessful login. Some targets may want to perform some kind of 
authentication. The Authenticator key is defined for this purpose. 
Various authentication schemes can be used, including encrypted 
passwords and trusted certificate authorities. Once the initiator 
and target are confident of the identity of the attached party, the 
established channel is considered secure. It is anticipated that 
most target devices will not bother with all of the possible 
checks, but the protocol provides sufficient means to perform the 
checks, if required by the target. 

6.4. ICANN Considerations 

There will be a well known port for iscsi connections. This well 
known port will have to be registered with ICANN. 

A checksum type will also have to be registered with ICANN. 



Sat ran, Smith, Sapuntzakis, Meth [Page 54] 

□ 

iSCSl June 2000 



7. Authors' Addresses 



Julian Satran 
Kalman Meth 

IBM, Haifa Research Lab 

MATAM - Advanced Technology Center 

Haifa 31905, Israel 

Phone +972 4 829 6211 

Email : Julian_Satran@vnet.ibm.com meth@il-ibm.com 



Daniel F. Smith 

IBM Almaden Research Center 

650 Harry Road 

San Jose, CA 95120-6099, USA 

Phone: +1 408 927 2072 

Emai 1 : df smi th@al maden . i bm , com 



Costa sapuntzakis 
Cisco Systems, inc. 
170 W. Tasman Drive 
San Jose, CA 95134, USA 
Phone: +1 408 525 5497 
Emai 1 : csapuntz@ci sco . com 



Page 45 



draf t-satran-i scsi -01. txt 

Randy Haagens 
Hewlett-Packard Company 
8000 Foothills Blvd. 
Roseville, CA 95747-5668, USA 
Phone: +1 (916) 785-4578 
E-mai 1 : Randy_Haagens©hp . com 



Efri Zeidner 

SANGate 

Israel 

efri ©sangate . com 



Sat ran, Smith, Sapuntzakis, Meth [Page 55] 

□ 

iSCSI June 2000 



Paul von Stamwitz 
Adaptec, Inc. 

691 South Mil pitas Boulevard 

Mil pitas, CA 95035 

Phone: (408) 957-5660 

E-mai 1 : paul v@corp . adaptec . com 



Luciano Dalle Ore 

Quantum Corp. 

Phone: +1 (408) 232 6524 

E-mai 1 : 1 uci ano . dal 1 e . ore@quantum . com 



Comments may be sent to Julian Sat ran 



Page 46 



draft-sat ran-i scsi -01. txt 



Sat ran, Smith, Sapuntzakis, Meth 

□ 

iSCSl June 2000 



[Page 56] 



8. References and Bibliography 

[SAM2] ANSI X3. 270-1998, SCSl-3 Architecture Model (SAM-2) 
[TLS] The TLS Protocol, RFC 2246, T. Dierks et al . 

[ALTC] Internet Draft: Alternative checksums (work in progress) 

[CAM] ANSI X3.232-199X, Common Access Method-3 (Cam-3) 

[CRC] ISO 3309, High-Level Data Link Control (CRC 32) 

[RFC793] Transmission Control Protocol, RFC 793 

[RFC1122] Requirements for Internet Hosts-Communication Layer, RFC 

1122, R. Braden (editor) 
[SBC] ANSI X3-306-199X, SCSI-3 Block Commands (SBC) 
[SCSI2] ANSI X3. 131-1994, SCSI-2 

[SPC] ANSI X3.301-199X, SCSI-3 Primary Commands (SPC) 
[AC] A detailed proposal for Access Control, 3im Hafner, TlO/99- 
245 



Sat ran. Smith, Sapuntzakis, Meth 

□ 

iSCSI 



[Page 57] 



June 2000 

Page 47 



draft-sat ran-i scsi -01. txt 

9, Appendix A - Examples 



9.1. Read operation example 



I Initiator Function | Message Type | Target Function | 
4. ^ ^ 4. 

I Command request ISCSI Command (read)>» | I 

I (read) | I I 
+ + + + 

I I I Prepare Data Transfer | 
+ + + + 

I Receive Data | «< SCSI Data | Send Data | 
+ + + + 

I Receive Data | «< SCSI Data | Send Data | 
+ 4. 4. + 

I Receive Data | «< SCSI Data | send Data | 
+ 4. 4. 4. 

I I «< SCSI Response |Send Status and Sense | 
4. 4. 4. 4. 

I Command Complete | I I 
4. 4. 4. 4. 
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9.2. Write operation example 



+ + + + 

I Initiator Function] Message Type | Target Function | 

+ 4. 4. 4. 

I Command request |SCSI Command (WRITE)»>| Receive command | 
I (write) I I and queue it j 

4. 4. + 4_ 

I I I Process old commands | 
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+ + + 4. 

I I I Ready to process | 
I I «< RTT I WRITE command j 
+ 4. 4. + 

I Send Data | SCSI Data »> | Receive Data | 
4. 4. 4. + 

I Send Data | SCSI Data »> | Receive Data | 
4. 4. 4. 4. 

I I <«. RTT I I 
+ + + + 

I Send Data | SCSI Data »> | Receive Data t 
4. 4. + + 

I I «< SCSI Response |send status and sense | 
+ 4. 4. 4. 

I Command Complete | I I 
4. 4. 4. 4. 
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10. Appendix B - Login/Text keys 

10.1. Target 

Target : domai nname [/modi f i er] 
Examples: 

Target : di sk-ar ray . s j -bl dg-h . ci sco . com 
Target : di sk-ar ray . s j -bl dg-h . ci sco . com/di sk3 

This key is provided by the initiator of the TCP connection to the 
remote endpoint. The Target key specifies the domain name of the 
target, since that information is not available from the TCP layer. 
The target is not required to support this key. The initiator 
should send this key in the first login message. The Target key 
might be used by the target to learn the intended initiator view of 
the target. 

10.2. Initiator 
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Initiator: [domai nname[/modi f i er] ] Examples: 

Ini ti ator : sampl e . f ooba r . o rg 

mi ti ator : cl uster . f oobar . org/machi nel 

initiator: 

The Initiator key enables the initiator to identify itself to the 
remote endpoint. The domain name should be that of the initiator. 
A zero-length domain name is interpreted as "other side of TCP con- 
nection". The target may silently ignore this key if it does not 
support it. For more security, a certificate-based protocol [TLS] 
may be used on the channel and take precedence over this protocol. 

10.3. Authenticator 



Authenti cato r : <UTF8-St ri ng> Exampl es : 

Authenti cator :open-sesame 

The authenticator is a secret that the initiator uses to gain 
access to the target's LUNs. 
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10 . 4 . SendAuthenti cator 



SendAuthenti cator: yes Response: Authenti cator :<UTF8-String> Exam- 
ples: 

SendAuthenti cato r : yes 

-> Authenti cator :alakazam 

The SendAuthenti cator key is used to request from the party on the 
other side of the TCP connection to send its Authenticator. iscsi 
devices may refuse to grant access until proper authentication has 
been performed by the parties involved. 

10.5. useRTT 



UseRTT:<yes I no> Response: UseRTT : <yes | no> Examples: 

UseRTT: no 
-> UseRTT: no 

The UseRTT key is used to turn off the default use of RTT, thus 
allowing an initiator to send data to a target without the target 
having sent an RTT to the initiator. The default action is that 
RTT is required, unless both the initiator and the target send this 
key-pair attribute specifying UseRTT: no. Once UseRTT has been set 
to 'no', it cannot be set back to 'yes'. 

Access-lD:<accessid-in-text-format> 



10 . 6 . Authenti cati on-ini ti ator-chal 1 enge : <al eph> 
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10.7 . Authenti cati on-lm ti ator-Response : <beth> 

10 . 8 . Authenti cati on-Target-Chal 1 enge : <gi mel > 

10 . 9 . Authenti cati on-Target-Response : <dal et> 

Expires January 10, 2001 



sat ran, smith, Sapuntzakis, Meth [Page 61] 

□ 



Page 51 



